Mobile IP (MIP) is described in a number of documents developed in the IETF (Internet Engineering Task Force) (www.ietf.org). MIP provides for mobility management for a MN Home address (HoA) by tunneling packets at a Home Agent (HA) towards/from a MN Care of Address (CoA), at which the MN HoA is routable. MIP signaling between the MN and the HA, maintains the MN CoA/MN HoA binding at the HA, and updates it to each new CoA value as the MN moves between Access Routers, and hence across the routing topology.
The known MIP HA acts as both the end point for MIP signaling and also as the endpoint for MIP tunnel forwarding. The HA also issues routing adverts for the HoA prefixes at that HA, from which MNs are allocated HoAs. The MIP HA must have a security association with each MN, and also with any Foreign Agent (FA) through which the signaling traverses. This is to ensure that binding changes can only be made by authorized MIP nodes. The end result is typically a HA router platform with significant forwarding, mobility signaling and security processing responsibilities. The HA also has timely visibility of the topological location and movement of the MN which can be useful for Location Based Services, and for presence management. However, the processing and publishing of such information to application services places additional significant burdens on HA nodes. A further problem with HAs is that from a security and management perspective they should be ideally located behind a firewall in an applications server farm of the operator but this causes high volume, low value traffic to trombone through the firewall twice, i.e., to visit the HA and be onward forwarded to the MN.
FIG. 1 shows the prior art Mobile IP signaling between a MN 220, a FA 224 and a HA 230. Message 260 is a MIP Registration Request (RREQ) message from the MN 220 to the FA 224, whilst 261 is a RREQ from the FA 224 to the HA 230. This message flow can be used to register either a MN CCoA or a FA CoA into the HA 230 for the HoA of the MN 220. The MIP Registration Response (RREP) is from the HA 230 to the FA 224 and is shown as message 262, which is forwarded to the MN 220 as message 263. This confirms the installation of the mobility binding into the HA 230 and FA 224, between the MN HoA and the MN CoA. In the case of a registered FA CoA, packet flow 264 between a CN 250 and the MN HoA is received at the HA 230, and then tunneled to the FA CoA in tunnel 265. MIP signaling can alternatively employ a RREQ message 270 from the MN 220 to the HA 230, and a RREP message 271 from the HA 230 to the MN 220, to install a MN CCoA into the binding at the HA 230. Packet flow 272 shows a flow of packets between CN 250 and the MN 220, which when received at the HA 230 are tunneled to the MN CCoA using tunnel 273 according to the stored binding for the MN HoA. This binding can be installed using either the signaling messages 260, 261, 262 and 263, or alternatively messages 270 and 271.
A redundant pair of HAs, synchronised with Virtual Router Redundancy Protocol (VRRP), is generally considered to be the optimal deployment configuration for an all-IP mobility domain, with any HA failure then being hidden by the synchronization protocol with the redundant HA. However, as the need grows to integrate mobility events with value-adding processes, including external application servers, this centralized (hot standby) architecture becomes more and more of a bottleneck as the amount of state, e.g., MN communication state and related information, to be synchronized grows.
In view of the above discussion, it should be apparent that there is a need for improved methods of providing functionality of the type provided by existing HA's while hopefully avoiding some of the problems with existing HA implementations.